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METHOD AND SYSTEM FOR ENABLING THE EXCHANGE, MANAGEMENT 

AND SUPERVISION OF LEADS AND REQUESTS IN A NETWORK 

RELATED APPLICATION 

[0001] This application is based upon provisional application Ser. No. 60/187,667, entitled 
"METHOD AND SYSTEM FOR ENABLING THE EXCHANGE, MANAGEMENT AND 
SUPERVISION OF LEADS AND REQUESTS IN A NETWORKED COMPUTER SYSTEM," 
filed on March 8, 2000 for Yali Harari, Shimon Lior Rokach, Ethan Klevansky, Ben Zion Galili, 
and Igor Tsenter. The contents of this provisional application are fully incorporated herein by 
reference. 

FIELD OF THE INVENTION 

[0002] The present invention relates to the field of trafficking and supervising leads and 
requests in a networked computer system, or other networked system. 

BACKGROUND OF THE INVENTION 

[0003] Persons who seek a product, service or information will frequently search for an 
entity that may fulfill his needs. This may be done manually, or semi-automatically by logging 
on to a computer, or by accessing the World Wide Web. For example, when a person finds an 
entity that he believes can fulfill or handle his request, he typically submits a request to that 
entity. This entity will be referred to herein as the provider. Upon receiving the request, the 
provider may: 



(1) process or answer the request by supplying the requested product, service, advice, 
or information; 

(2) forward the request, either manually or semi-automatically, to a partner of the 
provider; or 

(3) forward the request, again manually or semi-automatically, to another provider in 
a network, if such a network exists. 

[0004] In practice, however, providers frequently encounter difficulties processing such 
requests. These difficulties can result from several causes: 

• The provider can be overwhelmed by too many requests, some of which it cannot 
handle (for instance because the requester didn't fill in all required information, or 
because the requester asks for information, or a service that the provider can't 
provide), or a request that the provider does not wish to handle (see 2 and 3 
above). 

• The provider can encounter difficulty routing the request to its partners, and this 
can result in a low level of service, and/or lower profits to the provider from 
business relations with its partners. 

• The provider may not get a request that has been submitted to one of the 
provider's partners (requests that might be relevant to the provider). 

• A request that neither the provider nor its partners can handle is seldom responded 
to. This typically is because the provider either does not know who to forward the 
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request to, or because the provider does not stand to profit from routing the 
request. As a result, the requester receives a low level of service. 

[0005] Due to the fact that a request may be handled by different end-providers who may use 
different kinds of messaging technologies (e.g., e-mail, phone, fax, or web form), there are also 
difficulties in supervising the handling of requests. For example, the provider that received the 
original request typically cannot track the status of the request after it has been routed to a partner 
of that provider. 

[0006] What is desired, therefore, is a system and method for enabling the exchange, 
management, and supervision of leads and requests, in a networked computer system, that 
overcomes the above-described handling, and supervising difficulties of conventional systems 
and methods. 

SUMMARY OF THE INVENTION 

[0007] This invention provides a method and a system for enabling the exchange, 
management, and supervision of the handling of leads and requests, to a provider, in a networked 
computer system. 

[0008] The system and method disclosed overcome the disadvantages of the prior art by 
facilitating the exchange of requests between non-competing providers partners) helping 
ensure that each provider will get relevant requests from its partners, and that the number of 
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irrelevant requests a provider needs to process will be decreased dramatically. The system and 
method disclosed also overcome the disadvantages of the prior art by providing a mechanism for 
supervising the handling of requests. 

[0009] In particular, in one embodiment of the present invention, a method and system for 
processing a user request for services, from a user, is disclosed. The system includes a first input 
configured to receive request data from a user, a second input configured to receive a routing 
policy from a provider, wherein the routing policy includes a plurality of rules. Each rule is 
interpretable and/or executable by a computer. In addition, the method and system include a first 
processor configured to receive the request data from the first input and the routing policy from 
the second input, and to make a routing decision based at least on the request data and/or a user 
profile, to an end-provider, according to the routing policy. In addition, the routing decision can 
be further based on end-provider profiles. Further, the method and system include a first output 
configured to receive the routing decision from the processor, and route the request data to at 
least one end-provider according to the routing decision. 

[0010] As an aspect of this embodiment, the request data is formatted into a data oriented 
structure, such as XML. Accordingly, the computer processes the routing policy using the data 
structure. 

[0011] As a further aspect of this embodiment, the routing policy includes an instruction not 
to route the user request to a predetermined competitor of the provider. The routing policy may 
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also include an instruction to forward a notification to the user if at least one end-provider has 
not accepted the user request within a predetermined period of time. The routing policy may 
further include an instruction to forward the user request to a non-partner provider if at least one 
end-provider has not accepted the user request. In addition, the routing policy may require a 
processing of the user request within a predetermined period of time. Further, the routing policy 
may determine the order in which the user request is processed in relation to a plurality of other 
requests. 

[0012] In another embodiment of the present invention, a method and system for a provider 
to configure and manage a request service, where the request service processes user requests for a 
service, from one or more users, is disclosed. In the method and system, the provider subscribes 
to the request service. Further, the provider provided a request form definition to the request 
service, where the request form definition defines request data fields, such that a subsequent user 
request for a service includes request data corresponding to the request data fields. The provider 
further provides a routing policy to the request service to determine the protocol for routing said 
request to at least one end-provider, such that the request is routed based on the request data to at 
least one end-provider based on the routing policy of the provider. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0013] The following detailed description, given by way of example and not intended to limit 
the present invention solely thereto, will best be understood in conjunction with the 
accompanying drawings, in which: 
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[0014] FIG. 1 shows a block diagram of a preferred embodiment of the invention. 

[0015] FIG. 2 shows a block diagram for a method of request routing from an end-provider's 

point of view. 

[001 6] FIG. 3 shows a block diagram of a system for the routing of a request to an in-house, 
or internal provider. 

[001 7] FIG. 4 shows a block diagram for a method of request routing from a user's point of 
view. 

[001 8] FIG. 5 shows a block diagram of a system for routing a request to a provider within a 
company, entity, or organization (i.e., in-house routing). 

[0019] FIG. 6 shows a block diagram of a system for routing a request to a business partner, 
or external to a provider. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
[0020] For purposes of this application, "Subscribing provider" means a provider that joins a 
lead/request service. "Provider" means subscribing provider. Hereinafter, "person" will be 
referred to throughout this discussion as a requester, and "entity" or "company" will be referred 
to as a provider. Providers frequently have business associates or sub-contractors that they work 
with; these will be referred to as partners. "End-provider" means the provider that ultimately 
handles the request (also referred to as an "executing provider") which may be the provider, a 
partner of the provider, or a non-affiliated provider. Further, the "end-provider" means the actual 
resource in the provider which supply the service, such as a knowledge worker or expert in the 
organization. In addition, although the preferred operating systems, languages, formats, 
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databases, and software is provided, it should be understood that any desired operating system, 
language, format, database, and software may be utilized with the present invention, as desired. 

[0021] Figures 1, 2, 3, 4, 5, and 6 provide a more detailed illustration of the system and 
method in accordance with the invention. 

[0022] Fig. 1 is an illustrative example of a block diagram of a lead system for implementing 
an embodiment of the present invention. The computer system includes a user/requester 
computer (I), an end-provider computer (II), a lead system computer (III), the provider server 
computer (IV) and a network communications mechanism (V). Note that Fig. 1 may be modified 
as desired. 

[0023] The network communications mechanism provides a mechanism for facilitating 
communication between the requester computer (I), the lead service computer (IV), the end- 
provider computer (II), and the provider server computer (III). 

[0024] The requestor computer includes processor (1 8), a memory (10), and an interface for 
facilitating input and output in the requester computer (16). The memory stores a number of 
items, including operating system (14), and a web browser (12). The preferred operating system 
is Windows NT from Microsoft Inc. The preferred browser supports HTML, XML and 
JavaScript, such as Internet Explorer from Microsoft Inc. The request is provided by the 
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requester computer by filling in a request form that was supplied by the provider web server. 
[0025] The requester may also submit his request using other methods such as: 

A. Sending an e-mail to the provider's mail address. In that case the provider should 
support request form that is built into an e-mail structure that contains: From, To, 
CC, BCC, Title and body, and any other data that can be read from an e-mail 
message, such as the date of submission, mime type, etc., in case any of these are 
needed by the provider to conduct business. 

B. Using a wireless or other mobile device or a static device, which is capable of 
filling in the forms. 

C. Using a special application provided by the provider and should be installed on 
the requester computer. 

[0026] The end-provider computer includes processor (28), a memory (20), and an interface 
for facilitating input and output in the requester computer (26). The memory stores a number of 
items, including the operating system (24), and a web browser (22). The preferred operating 
system is Windows NT from Microsoft Inc. The preferred browser should support HTML, XML 
and JavaScript, such as Internet Explorer from Microsoft Inc. 

[0027] The provider server computer includes processor (38), a memory (30), and an 
interface for facilitating input and output in the requester computer (36). The memory stores a 
number of items, including the operating system (34), and a web server (32). The preferred 
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operating system is Linux from Red Hat, Inc. The preferred web server is Apache, available over 
the Internet at http://www.apache.org. Note that the end-provider may also be the provider. In 
such a case, Fig. 1 would not include End-Provider Computer (II); instead, memory 30 of 
Provider Server Computer (II) would further include a web browser 22. 

[0028] The lead service computer includes processor (48), a memory (40), and an interface 
for facilitating input and output in the requester computer (46). The memory stores a number of 
items, including the operating system (44), and a web server (42), database software (45), and a 
policy virtual machine (PVM) service application (47). The lead service computer comprises the 
policy virtual machine service application which process the provider's policies, as described 
above. The provider's policy can be written in a script language like Visual Basic Script or 
JavaScript. 

[0029] An administrative tool can be employed when adding a new provider to the system. 
An administrative tool may also be used in setting up the system configuration for the new 
provider (which may include designing the provider's forms, policies, partners, etc.) The 
preferred operating system is Linux from Red Hat, Inc. The preferred web server software is 
Apache, available over the Internet at http://www.apache.org. The preferred database is Oracle 
from Oracle, Inc. 

[0030] The database software stores the provider's request form, the request information, the 
provider's policy scripts, the end-provider's profile templates, and the end-provider's profile 



9 



information. It should be noted that the same lead system might serve several different 
providers. 

[0031] The following describes a preferred format to be used to form a company record from 
the provider information: 

Provider Number, 

Provider Name, 

Provider Policy Script, and 

Provider Request Form. 

[0032] The preferred language to be used to describe a company's policy script is JavaScript. 
The preferred format to be used in the description of a provider's request form is XML. 

[0033] The following describes a preferred format to be used to form a request record from 
the request information: 

Request Number, 

Request's Company (i.e., where the request has been submitted), 
Request's Origin Provider, and 

Request Information (based on the provider request form). 

[0034] The preferred format to be used for describing request information is XML. The 
following is, a description of the preferred format of the end-provider record: 
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End-provider Number, 
End-provider Name, 
Provider Number, and 
E- mail Address. 

[0035] As stated above, the provider's policy can be stored as Java Script, or in any other 
computer interpretable format. The request data, or any other data used to route the request, such 
as an end-provider profile, or a user profile, can be formatted in XML, or in any other suitable 
data structure. This invention may route the request based only on the computer interpretable 
policy, or based on the computer interpretable policy coupled with a data structure containing 
some or all of the above described information. Two examples of the use of a computer 
interpretable rule based policy coupled with a data oriented structure are as follows: 

Example 1 of a Routing Policy Rule: 
[0036] a. Rule: 

If the income of the user/requestor is greater than $100,000, then route the request to 
expert A 123. 

b. Routing Policy Rule in Interpretable Programming Language Format: 

If(request.getFieldC'Income")>100000) then 

{ 

requestrouteToProvider(" Al 23 "); 

} 
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Example 2 of a Routine Policy Rules: 
[0037] a. Rule: 

Route the request to an expert that has "income" attribute closest to "income" attribute of 
requestor. 

b. Routing Policy Rule in Interpretable Programming Language Format: 
Request.routeToProviderByAttribute(' l income' , ,"close",Request.getField(''Income")) 

[0038] It should be noted that the computers of the requester, the end-provider, the lead service, 
and the provider server, may all contain additional components not discussed above, such as a 
keyboard, a mouse, a magnetic storage device, or a CD-ROM. 

[0039] The computers described above may either be general or special purpose computers that 
perform the operations as described above. One skilled in the art would appreciate that the use 
of the above described methods and systems is not limited to a particular computer configuration. 

[0040] The data and information referred to herein represent physical quantities. These 
quantities typically take the form of electrical or magnetic signals capable of being stored, 
transferred, combined, compared, or otherwise manipulated. While these data may be referred to 
by various labels, such as information, requests, rules, policies, or the like, these terms, and 
similar terms used herein refer to physical quantities, and are merely convenient labels. The 



12 



described data operates, resides, flows, is transferred or are otherwise manipulated by, or in, a 
computer, as described above, which includes a server, or a network of servers and/or computers. 

Using the System from an End-provider's Point of View 

[0041] Figure 2 illustrates the lead system from the point of view of the end-provider. The end- 
provider logs onto the request system (step 50). In one embodiment this may be through a secure 
connection, over the Internet, or through an intra-net of the end-provider. The end-provider 
inspects a request queue that contains a list of all of the requests that have been routed to that 
end-provider through the lead system (step 52). After the end-provider selects a request from the 
queue, the end-provider can choose to interact with the requester, either to provide an answer, 
provide a quote, get additional information, or to ask for a clarification (step 54). The requester 
can be satisfied with the answer, service, or quote provided by the end-provider (step 56), or the 
requester can reject the answer, service or quote, and direct that the request be redirected towards 
another end-provider (step 58). 

[0042] The typical embodiment of the method may be described from the provider's point of 
view as follows: 

[0043] The provider has several queues of requests routed to it by the lead system. The request 
will be handled by an end-provider of the provider. The end-provider may view a list of the 
requests, or the details of a specific request, and, according to his/hers privileges, the end- 
provider can choose an action which may include but is not limited to: 
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• Add the request to his/her list of "pending" requests - requests that he/she will be 
handling. In the case where the request was addressed to a group of providers 
within the provider, doing this will lock the request to the other end-providers of 
the group, and they will not be able add it to their "pending" requests list. The 
provider then interacts with the requester in order to refine the request, make the 
requester a service offer, answer the request, etc. 

• Reject the request. Depending on the providers privileges in the system, this 
action might mark him/her as further unsuitable to handle this request, move the 
request from his/her personal queue or remove the request from the group's queue, 
In the later case, this will cause the request to be rerouted by the provider policy 
mechanism, without rerouting to providers/groups that have rejected it in the past. 

• Reroute the request to another end-provider/end-provider group from within the 
subscribing provider. This too will be performed according to end-provider's 
privileges. 

• Reroute the request to another end-provider/end-provider group external to the 
subscribing coiporation, that is either a business partner or any other subscribed 
company. This too will be performed according to provider's privileges. 

Configuring the System 

[0044] The present invention is highly configurable by the provider. During a subscription 
process, each subscribing provider describes in a subscription form what industry it is involved 
in (e.g., commerce, support, or service). Additionally, the subscribing provider can describe 
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what areas of that industry it is involved in. This may be done, for example, by relating the 
provider to one or more categories in a category tree, or a category list. 

[0045] Each provider can design a request form that is specific for that provider. The request 
form contains the information needed by the provider to process the request. The request form 
can be built either statically, or dynamically, from a list of data items included in a request form 
definition. These data items may include fields such as: numbers; free-text; a selection from a 
list of values; a file; etc. The request information form can contain several logical types of data: 

• System Required Data: Data essential for the system to function, such as user, or 
requester identification. 

• Application Required Data: Data agreed to by the providers that share the same 
network. This data is essential for routing requests between different providers. 
For example, the data may be composed of an offered price for a requested 
service. 

• Proprietary Routing Data: Data that a provider needs in order to perform inner 
policy decisions (as defined hereafter), but this data is not common to other 
subscribed companies of the lead services. An example of this data is the number 
of employees in the requestor's organization. 

• Variant Data: Data that can be added to the request to satisfy the needs of specific 
application, without having an implication on the policy decision process. 
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[0046] The request form definition could also be made by another entity, or by the lead system. 
Besides the request form, the provider can define responses, in an event policy, to actions that 
might be performed by the requester, by the end-provider, or by any other system that may 
interfere with the present invention. For each action, the provider can also attach an interaction 
form that is filled in by the entity that has performed the interactions to provide feedback for the 
provider. 

[0047] A provider can create a profile of possible end-providers. This profile can be used to 
assign incoming requests to an appropriate end-provider. The provider can then manage its end- 
providers by adding their information to the system, organizing them into groups, and defining 
their privileges to perform actions. 

[0048] During the subscription process, the provider may also identify partners that the provider 
would like to route requests to, in the event that the provider declines to handle a request. A 
provider may also attach a policy script for each business event that may occur. Each script 
might be executed immediately after the corresponding event occurs. A perfect practice is to 
attach a policy to each form designed by the provider. For instance, the provider may define an 
"Arrival of Request" policy, which will be executed the moment a new request form is fed into 
the system. The provider may use the "Arrival of Request" policy as an opportunity to define a 
routing policy for new requests. Using the information filled in by the requester, the routing 
policy governs the routing of a request to an end-provider. 
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[0049] As an example, it may be desirable to offer policies for the following events: "End- 
provider sends a message to the requester"; "End-provider sends a service or product quote to the 
requester"; "The end-provider provides the requested information"; "The requester accepts the 
quote"; or "The requester declines the quote." One skilled in the art would appreciate that the 
above list is not intended to be exhaustive. A policy may be attached to any event. The provider 
may also define an event to attach a policy to, based on another policy, and not based upon a user 
action. A policy can be based on a list of "if-then" rules. Each rule has a condition, and a list of 
actions to be performed when said condition is satisfied. 

[0050] A condition is built from Boolean literals that are combined using Boolean operators like 
AND, OR, or NOT. Generally each Boolean literal contains a reference to one of the request's 
fields (for instance, the requester's annual income), a reference to the operator, and the compared 
value (that can manually be filled in or be a reference to another field). The operators include 
arithmetic operators (Le„ =, <, >) and string operators (i.e., "contains," "starts with"). Other 
complicated rules might include reference to a collection of fields, or to other data from the 
system, such as data related to former events (when did they occur, etc.). Actions can be of any 
type that is performed on a request to change its status or its data. This would include assigning 
the request to an "end-provider", or a group of "end-providers," sending a notification, routing 
the request to a partner, the transferring of a request between different end-providers, rejecting 
the request, locking the request, etc. Actions can also be related to other entities located within 
the system or beyond {Le., communicating data to external systems, etc.). 
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[0051] The routing policy may define the following: 

• Under what conditions the request should be handled by the provider itself, and to 
what end-provider(s) or computer(s) the request will be routed. In the case of 
routing to a computer, the response to the requester can be automatic. 

• Under what conditions the request will be routed to one or more of the providers 
(who have already been identified by the provider). 

• Under what conditions the provider agrees to route the request to other subscribed 
providers, which are unknown in advance, and are not competitors, but are willing 
to handle the request. 

• The provider may also define whom it considers a competitor. 

[0052] Upon occurrence of an event, the system should be fed with a record containing the event 
type, the data required for executing the policy attached to this event type, and the execution time 
of the policy (which can be an ASAP execution, or a specific date and time). The above record is 
stored in a queue that is sorted according to the execution time. The system will poll one record 
at a time (the queue can only poll records whose execution time has come) and invokes the 
policy script, thereby deciding what actions should be performed by the system. The data 
attached to a record is stored in the system's database for future use. The system could be fed 
records from various sources. For example, the system could be fed by an ERP or Workflow 
system, or by the system itself (when one policy invokes another policy). 
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[0053] Upon the arrival of a request, which may come directly from the requester, or be routed to 
the provider, by the lead system, the request data and a reference to the corresponding event type 
("Arrival of Request") is stored in the queue. When the time has come for the system to process 
the request, it will, according to the provider "Arrival of Request" policy script, determine what 
actions should be performed on the request. For instance, the system may use the "Arrival of 
Request" policy to decide which end-provider should be assigned to handle the request. 

[0054] If according to the provider policy the request can be handled "in-house," then the request 
is routed internally (either automatically or manually) to a suitable end-provider or end-provider 
group. The request will then be appended to one of the pending lists of the chosen end-provider, 
either in a queue, or a buffer. An authorized end-provider may connect to the lead system, and 
view the provider's pending lists according to his/her privileges. The end-provider can scan the 
list, and either decide to handle the request, or decide the request should be assigned to a 
different pending list of the provider, or decide whether the request should be routed externally to 
the provider or provider group, such as to a partner of the provider. "In-House routing" refers to 
inner routing, indoor routing, or to the routing of a request within a company. Figure 3 
illustrates an example of in-house routing. A request (step 60) is received by the PVM of the 
provider (step 62). Based upon the PVM (step 62), the request (step 60) is routed (step 67) to a 
queue of an end-provider that is a sub group of the provider (steps 64(a)-(d)). The end-provider 
can decide to handle a request, reject it (step 68), or move the request to another end-provider 
(step 69). Alternatively, the request (step 60) can be originally routed to the end-providers (steps 
64(a)-(d)) by the workflow manager (step 66). 
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[0055] If the end-provider decides to handle the request, the request will be moved to the end- 
provider's personal pending list. From this personal list, the end-provider may interact with the 
requester according to interaction forms that have been defined by the provider (e.g., messaging, 
provide the service, provide the requested information, write service or product quote). This 
process proceeds until the request is declared as "handled," or until the end-provider decides to 
deliver the request to another pending lists for further handling. The type of actions an end- 
provider can perform is defined according to that end-provider's system privileges. 

[0056] It should be noted that the provider can decide, as part of its policy, that in order to 
interact with an end-provider(s), other than the provider, the requester will be required to log in 
through the provider's original entry point into the system (e.g., web site). 

Using the System from a Requester's Point of View 

[0057] Figure 4 illustrates one embodiment of the present invention. A user contacts a lead 
system (step 70). In one example this could be via a home or mobile computer device. The user 
submits a request containing request information to the lead system (step 72). This could be via 
a World Wide Web page, or other electronic interface. The lead system routes the request to an 
appropriate end-provider(s) the mechanics of which are disclosed below (step 74). Finally, the 
end-provider(s) interact with the user until the request has been satisfactorily answered (step 76). 
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[0058] The method begins when a requester connects to a provider server, and describes its 
request by filling in a request form that is provided by the provider. A provider server may, for 
example, be a web site on the World Wide Web, but need not be. 

[0059] The typical embodiment of the method might be described from the user or requester's 
point of view as follows: 

[0060] A requester enters a networked section of the system, for example an Internet site of the 
provider, where he/she can provide data about a request he/she has (e.g. , a request form). After 
the request is submitted to the lead system, the requester might be notified by the system by 
means of a network (e.g., e-mail, WAP, or web dynamic pages) when a provider has responded 
to the request, or when several providers have responded. If no provider has responded within a 
period defined by the requester, and/or by the subscribed company, the lead system can 
optionally notify the requester that the company cannot handle the request. To accomplish the 
above delayed notification, the provider should use a policy that is initialized by the policy 
attached to the "Arrival of Request" event. 

[0061] The requester may then add information to his request or interact with the provider(s) 
using the various interaction forms defined by the provider, receive information, such as a quote 
for the service or product, and trade with the provider(s) within the system. This process of 
interaction might be lengthy, or short, on-line, or with breaks. 
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[0062] In the case where a requester has logged out, or disconnected from the system, the system 
will request identification data the next time the requester logs in/connects to the system, and 
then refer the requester to his/her current unanswered requests. 

[0063] After a provider has supplied a sufficient answer to the requester's needs, the requester 
can acknowledge that he/she has been satisfied by the response, and the request can then be 
marked as "complete." 

Using the System from the Provider's Policy Manager's Point of View 
[0064] The process may be described from the provider's policy manager's point of view as 
follows: One or more policy managers may log into the lead service to perform maintenance 
tasks, such as the change of request data forms or any other forms, changing event policies, or to 
view and manage request data, such as processing reports, or the handling of exceptions. The 
policy managers have interfaces enabling them to change and verify policies, enforce rules, such 
as regarding provider's and partner's privileges. 

The Routing of Requests 

[0065] A requester, through a computerized request generating mechanism, initiates a request. 
The request is submitted after the requested data is filled in by the requester. The request may be 
submitted via a submitting mechanism to a lead system. A submitting mechanism, however, 
does not have to be a part of the lead system. The lead system, however, generally operates 
according to the policies defined in the requests. 
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[0066] The lead system has a routing mechanism. The routing mechanism of the lead system 
receives the request and marks the source of the request on the request. The request data 
structure is of a type that can be manipulated dynamically, and additional data may be added to it 
by processing mechanisms, such as the routing mechanism, at any time. Marking the request is 
essentially adding data to the request, such as by adding a cookie. The routing mechanism routes 
the request according to the rules defined in the source company's policy. 

[0067] Assigning a request to an end-provider or to a group of end-providers can be 
implemented by three different methods: 

1 . Explicit Assignment: An explicit assignment is the assignment of the request to a 
specific end-provider, or to a specific group of end-providers. For instance, if the 
requestor lives in NY, and his income is greater than $100,000, then assign the 
request to Roger Ross, and if the requester's income is less than $100,000, or the 
requester does not live in New York, then assign the request to the Non-VIP 
group. 

2. Inexplicit Assignment: The assignment of the request to end-providers that fulfill 
specific conditions: For instance, assign the request to all end-providers that work 
in NY, and are categorized as senior advisors. 

3 . Automatic Assignment: The assignment of the request by classifying the request 
to the appropriate end-provider. To achieve this goal, one can use a classification 
algorithm, taking into consideration that the request may be assigned to more than 
one end-provider, and that the classification algorithm should be able to handle 
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different types of information items (for instance, number, category values and 
free-text). A relevant embodiment will be using the Support Vector methodology 
as described in Vapnik V. (1998). Statistical Learning Theory. Chichester, UK: 
Wiley, the contents of which are incorporated herein by reference. 

[0068] The routing mechanism routes the request to a provider, to a business partner, or to 
another subscriber provider on the World Wide Web, as follows: 

• Inner routing: To a provider or provider group within the company. 

• BP Routing: To a business partner or business partners of the company. 

• WWW Routing: To the "World Wide Web" Service within the lead system, 
meaning the lead system can reroute the request to any subscribed company it 
finds suitable (non-competitive with the source company). 

[0069] The lead system provides a further routing mechanism that routes the request within the 
provider to aa end-provider. That occurs according to end-provider specific policies. 

[0070] The lead system may also supervise the handling of the request. Such supervision may 
be accomplished by marking any request for further tracking and inspection and define time and 
event driven actions, such as tracking the processing of a request routed to the "support" queue 
inside the company, and if not answered within three days, reroute it to another provider, such as 
a management group. 
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In-House Routing 

[0071] In-house routing is routing within the company. This routing is a process where a request 
is sent to a provider that is comprised of a group of end-providers. It is understood that 
"provider" means one or more end-providers within the provider. 

[0072] Figure 5 illustrates the routing of a request within a provider. At steps 80 and 82, 
Organization (hereinafter, "Provider") A receives on its network the user request. At steps 84 
and 86, Provider A routes the request to an appropriate end-provider in provider A or to a group 
of end-providers (not shown) in provider A according to policy. However, should the end- 
provider within Provider A be unwilling or unable to handle the request, the request reroutes to 
another provider, Provider B, at step 88. 

[0073] The policies specific to the provider govern how the request is further routed to a queue 
in a computer of an end-provider. According to his/her privileges, the provider(s) can then: 

• "Take" the request, meaning to lock it so as to prevent other providers/end- 
providers from handling it. 

• "Block" the request, meaning to mark it so that the request cannot be routed to 
that provider again. Thus, the provider will not be fulfilling the request. 

• Rej ect the request, meaning, returning it to the routing mechanism for rerouting, 
marking it not to return to the queue it came from. 
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• Forward to another provider, in-house or externally (take the action of the type the 
routing mechanism does), moving it to that provider's queue and removing it from 
the current provider's queue. 

Routing to a Partner 

[0074] When a company's policy defines that a request is to be routed to, and handled by a 
business partner, or when a system user (i.e., provider or manager) defines that a request should 
be routed to a provider outside of the company, the lead system will move or reroute the request 
to the other company's entrance point, which means that it will reroute the request using the 
second provider/company's policy. This procedure is identical to the situation where the request 
is initially sent to the second company's routing mechanism, only that the source of request data 
will not be run-over, or marked, with the first company's source information. Rather, the original 
source, or marking of the request, will be preserved. From here on, the routing is operated by the 
lead system in a manner similar to the routing described. 

[0075] Figure 6 illustrates an example of routing outside of a provider. At steps 90 and 91, 
Organization (hereinafter, "Provider") A receives on its network the user's request. At step 92, 
the system decides, according to Provider A's policy, whether to route it internally (Step 93), to a 
partner (Step 94), or to WWW routing (Step 97). In step 95, the request can then be routed to the 
most appropriate end-provider in Provider B or the most appropriate end-provider's group. The 
system avoids routing the request to competitors of the original provider. 
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WWW Routing 

[0076] When a company's policy defines that the company's providers would not handle a 
request, and nor will the company's business partners, the lead system may, according to the 
policy defined by the source company, reroute the request to a center lead system, that might 
identify a subscribed company(s) willing and fitting to provide for the request, I. If so, the 
subscribed company's routing mechanism(s) will process the request and respond according to 
policies. The identification of a subscriber company in the center lead system is on the World 
Wide Web, 97. The request service can assure that the non-affiliated provider, 98, is not a 
competitor of the original provider, if the original provider so desires. 

[0077] The method is illustrated by the following examples: 

[0078] Example 1: A software company, A, develops different software products. A does not 
sell such products to small companies, but uses subcontractors/resellers in different geographic 
areas for selling the products to small organizations. Furthermore, A does not supply any 
application consulting services for its products. However, A does supply general and marketing 
information and provides customer support for several of its products. 

[0079] A customer (i.e., requester) who is interested in buying one of A's products, or in 
retaining the services of a consultant who may consult concerning such products, may have the 
wrong impression that A handles all kinds of requests. For that reason, he will probably fill in a 
request form in A's web site for any services or products that pertain to A's products. 
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[0080] To handle the requests, the company may design a request information form that will 
include the following fields: 

• The contact information of the requester, including physical address, and e-mail 
address. 

• Information about the requester organization, if any, for example: yearly revenue, 
and/or the number of employees. 

• The name of the product that the requester is interested in. 

• The type of request: i.e., general information inquiry, consulting, purchases, 
support, etc. 

• The description of the request in free text. 

[0081] The policy of A or its "provider policy script" may be composed of rules, an example of 
which follows: 

• If the requester wants to get general information about one of the products, the 
request will be routed to the suitable group in the marketing department that 
handles this product. 

• If the requester wants to buy one of the products, and his organization is bigger 
than 500 employees, then the request will be routed to the suitable group in sales 
department that handles this product. 

• If the requester wants to buy one of the products, and his organization is smaller 
than 500 employees, then the request will be routed to the suitable reseller 
(partner) according to the requester's location (the requester address). 
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• If the requester wants support on a product that is supported by A, then the request 
will be routed to the suitable group in the support department that handles this 
product. 

• If the requester wants support on a product that is not supported by A, then the 
request will be routed automatically by the service to other companies subscribed 
to the service that may be able to provide the requested support. 

• If the requester wants consulting on one of A's products, then the request will be 
routed to A's business partners according to either the product, the requester 
organization, or the requestor's location. 

[0082] Example 2: A Human Resource department may use the present invention to support the 
smart matching and routing of resumes, personnel, open positions, and the hiring processes, 
based on sophisticated policies. On the receipt of a new resume, a corresponding policy will be 
invoked. A typical policy in this case might contain the following rule: "If there is a vacant 
position with the same skill set as an incoming resume, this resume is assigned to the appropriate 
manager, and issue an e-mail to the candidate saying that the resume is under review; but if there 
is no vacancy, then an e-mail is sent to the candidate, thanking him/her for his/her interest in the 
company." 

[0083] Whenever the appropriate manager reviews the resume, the manager might decide to 
schedule a meeting. In that case, the corresponding policy may schedule a meeting, and send an 
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e-mail notification to the candidate. Alternatively, the manager may turn down the candidate, 
and, in that case, an e-mail thanking the candidate could be issued automatically. 

[0084] Specific embodiments of the invention have been described herein for purposes of 
illustration only. One skilled in the art would appreciate that various modifications may be made 
to the embodiments described herein without departing from the spirit and scope of the 
invention. The spirit and scope of the invention may be defined by reference to the following 
claims, along with the full scope of their equivalents: 



30 



